Technologies for providing function as service tiered scheduling and mapping for multi-operator architectures

ABSTRACT

Technologies for determining a set of edge resources to offload a workload from a client compute device based on a brokering logic provided by a service provider include a device that includes circuitry that is in communication with edge resources. The circuitry is to receive a brokering logic from a service provider receive a request from a client compute device, wherein the request includes a function to be used to execute the request and one or more parameters associated with the client compute device, determine the one or more parameters, select, as a function of the one or more parameters and the brokering logic, a physical implementation to perform the function, wherein the physical implementation indicates a set of edge resources and a performance level for each edge resource of the set of edge resources, and perform, in response to a selection of the physical implementation, the request using the set of edge resources associated with the physical implementation.

RELATED APPLICATION

This patent arises from a continuation of U.S. patent application Ser.No. 16/234,865, filed on Dec. 28, 2018 and entitled “TECHNOLOGIES FORPROVIDING FUNCTION AS SERVICE TIERED SCHEDULING AND MAPPING FORMULTI-OPERATOR ARCHITECTURES,” which is incorporated herein in itsentirety.

BACKGROUND

Typically, a compute device may execute an application using resourcesthat are local to the compute device, such as a general purposeprocessor and/or one or more accelerator devices (e.g., devices capableof executing a set of operations faster than the general purposeprocessor). In some scenarios, a compute device may encounter a sectionof an application that should be performed within a certain set ofparameters (e.g., the section is particularly sensitive to latency, suchas a section that is to make decisions based on real time computervision data, and should be performed within a particular time period)but is unable to satisfy those parameters due to limitations of thecompute device. For example, the compute device might not be equippedwith a fast enough general purpose processor or an appropriateaccelerator device, or the compute device may not have enough energystored in its battery to execute the section within the specified timeperiod (e.g., utilizing the accelerator device would deplete theremaining energy in the battery).

BRIEF DESCRIPTION OF THE DRAWINGS

The concepts described herein are illustrated by way of example and notby way of limitation in the accompanying figures. For simplicity andclarity of illustration, elements illustrated in the figures are notnecessarily drawn to scale. Where considered appropriate, referencelabels have been repeated among the figures to indicate corresponding oranalogous elements.

FIG. 1 is a simplified diagram of at least one embodiment of a systemfor determining a set of edge resources to offload a workload from aclient compute device based on a brokering logic provided by a serviceprovider;

FIG. 2 is a simplified block diagram of at least one embodiment of aclient compute device included in the system of FIG. 1; and

FIGS. 3-6 are a simplified block diagram of at least one embodiment of amethod that may be performed by an edge gateway device of FIG. 1 fordetermining a physical implementation of a function to perform arequested workload from a client compute device.

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to variousmodifications and alternative forms, specific embodiments thereof havebeen shown by way of example in the drawings and will be describedherein in detail. It should be understood, however, that there is nointent to limit the concepts of the present disclosure to the particularforms disclosed, but on the contrary, the intention is to cover allmodifications, equivalents, and alternatives consistent with the presentdisclosure and the appended claims.

References in the specification to “one embodiment,” “an embodiment,”“an illustrative embodiment,” etc., indicate that the embodimentdescribed may include a particular feature, structure, orcharacteristic, but every embodiment may or may not necessarily includethat particular feature, structure, or characteristic. Moreover, suchphrases are not necessarily referring to the same embodiment. Further,when a particular feature, structure, or characteristic is described inconnection with an embodiment, it is submitted that it is within theknowledge of one skilled in the art to effect such feature, structure,or characteristic in connection with other embodiments whether or notexplicitly described. Additionally, it should be appreciated that itemsincluded in a list in the form of “at least one A, B, and C” can mean(A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).Similarly, items listed in the form of “at least one of A, B, or C” canmean (A); (B); (C); (A and B); (A and C); (B and C); or (A, B, and C).

The disclosed embodiments may be implemented, in some cases, inhardware, firmware, software, or any combination thereof. The disclosedembodiments may also be implemented as instructions carried by or storedon a transitory or non-transitory machine-readable (e.g.,computer-readable) storage medium, which may be read and executed by oneor more processors. Furthermore, the disclosed embodiments may beinitially encoded as a set of preliminary instructions (e.g., encoded ona machine-readable storage medium) that may require a preliminaryprocessing operations to prepare the instructions for execution on adestination device. The preliminary processing may include combining theinstructions with data present on a device, translating the instructionsto a different format, performing compression, decompression,encryption, and/or decryption, combining multiple files that includedifferent sections of the instructions, integrating the instructionswith other code present on a device, such as a library, an operatingsystem, etc., or similar operations. The preliminary processing may beperformed by the source compute device (e.g., the device that is to sendthe instructions), the destination compute device (e.g., the device thatis to execute the instructions), or an intermediary device. Amachine-readable storage medium may be embodied as any storage device,mechanism, or other physical structure for storing or transmittinginformation in a form readable by a machine (e.g., a volatile ornon-volatile memory, a media disc, or other media device).

In the drawings, some structural or method features may be shown inspecific arrangements and/or orderings. However, it should beappreciated that such specific arrangements and/or orderings may not berequired. Rather, in some embodiments, such features may be arranged ina different manner and/or order than shown in the illustrative figures.Additionally, the inclusion of a structural or method feature in aparticular figure is not meant to imply that such feature is required inall embodiments and, in some embodiments, may not be included or may becombined with other features.

Referring now to FIG. 1, a system 100 for determining a set of edgeresources to offload a workload from a client compute device based on abrokering logic provided by a service provider includes an edge gatewaydevice 110 in communication with the client compute device 120. The edgegateway device 110 may be embodied as any device capable ofcommunicating data between the client compute device 120 and one or moreedge resources 140, 150, 160, 170, 180 (e.g., resources, such as computedevices and the components thereof, owned and/or operated by one or moreservice providers, such as cellular network operators) or other computedevices located in a cloud. The edge gateway device 110 and the edgeresources 140, 150, 160, 170, 180, in the illustrative embodiment, arepositioned at one or more locations (e.g., in small cell(s), basestation(s), etc.) along the edge (e.g., in an edge network) of a cloud.In some embodiments, the edge gateway device 110 may be positioned at acore data center. It should be appreciated that the edge gateway device110 and one or more edge resources 140, 150, 160, 170, 180 may bepositioned at different locations.

The edge gateway device 110, in the illustrative embodiment, isconfigured to receive and respond to requests from the client computedevice 120 to offload a workload to the edge resources 140, 150, 160,170, 180, such as accelerator resources 140, 150, storage resources 160,compute resources 170, memory resources 180 and/or other edge resources.To do so, the edge gateway device 110 includes a brokering logic unit112, which may be embodied as any device (e.g., a field-programmablegate array (FPGA)) capable of scheduling a requested workload receivedfrom the client compute device 120 to a set of edge resources 140, 150,160, 170, 180. In use, the brokering logic unit 112 may determine theset of edge resources 140, 150, 160, 170, 180 that is capable ofperforming the requested workload based on requirements indicated by theclient compute device 120 (e.g., a function required to perform therequested workload, acceptable latency requirement to perform therequested workload, a service level agreement, costs (e.g., monetarycosts) associated with utilizing those edge resources 140, 150, 160,170, 180 to perform the requested workload, and/or a list of acceptableservice provider(s) of the edge resources). To do so, the brokeringlogic unit 112 receives a brokering logic from one or more serviceproviders that own or operate the one or more edge resources 140, 150,160, 170, 180. Each service provider may provide its own brokering logicthat is to be used to determine a physical implementation of thefunction to perform a requested workload. For example, the physicalimplementation of the function indicates a set of edge resources and anoperating mode (e.g., a performance level) for each edge resource.

An edge network may be embodied as any type of network that providesedge computing and/or storage resources which are proximately located toradio access network (RAN) capable endpoint devices (e.g., mobilecomputing devices, Internet of Things (IoT) devices, smart devices,etc.). In other words, the edge network is located at an “edge” betweenthe endpoint devices and traditional mobile network access points thatserves as an ingress point into service provider core networks,including carrier networks (e.g., Global System for MobileCommunications (GSM) networks, Long-Term Evolution (LTE) networks, 5Gnetworks, etc.), while also providing storage and/or computecapabilities. Accordingly, the edge network can provide a radio accessinterface to enterprise applications (e.g., housed in a remote cloud,data center, etc.) and/or other network-based services, as well as bringstorage/compute resources closer to the endpoint devices. As somecomputations/processing can be performed at the edge networks,efficiencies such as reduced latency, bandwidth, etc., can be realized(i.e., relative to such computations/processing being performed at aremote cloud, data center, etc.). Depending on the intendedpurpose/capabilities of the edge network, the edge network may includeone or more edge computing devices, which may include one or moregateways, servers, mobile edge computing (MEC) appliances, etc. Itshould be appreciated that, in some embodiments, the edge network mayform a portion of or otherwise provide an ingress point into a fognetwork (e.g., fog nodes), which may be embodied as a system-levelhorizontal architecture that distributes resources and services ofcomputing, storage, control and networking anywhere between a core datacenter (e.g., a data center that is further away from and in a higherlevel of a hierarchy of the system 100 than the edge resources 140, 150,160, 170, 180, and that includes multiple compute devices capable ofexecuting one or more services (e.g., processes on behalf of one or moreclients)) and an endpoint device (e.g., the client compute device 120).

Referring now to FIG. 2, the illustrative client compute device 120includes a compute engine (also referred to herein as “compute enginecircuitry”) 210, an input/output (I/O) subsystem 216, communicationcircuitry 218, and one or more data storage devices 222. As describedherein, the client compute device 120 may also include one or moreaccelerator devices 224. Of course, in other embodiments, the clientcompute device 120 may include other or additional components, such asthose commonly found in a computer (e.g., a display, peripheral devices,etc.). Additionally, in some embodiments, one or more of theillustrative components may be incorporated in, or otherwise form aportion of, another component. The compute engine 210 may be embodied asany type of device or collection of devices capable of performingvarious compute functions described below. In some embodiments, thecompute engine 210 may be embodied as a single device such as anintegrated circuit, an embedded system, a field-programmable gate array(FPGA), a system-on-a-chip (SOC), or other integrated system or device.In the illustrative embodiment, the compute engine 210 includes or isembodied as a processor 212 and a memory 214, described above withreference to FIG. 1. The processor 212 may be embodied as any type ofprocessor capable of performing the functions described herein. Forexample, the processor 212 may be embodied as a multi-core processor(s),a microcontroller, or other processor or processing/controlling circuit.In some embodiments, the processor 212 may be embodied as, include, orbe coupled to an FPGA, an application specific integrated circuit(ASIC), reconfigurable hardware or hardware circuitry, or otherspecialized hardware to facilitate performance of the functionsdescribed herein.

The main memory 214 may be embodied as any type of volatile (e.g.,dynamic random access memory (DRAM), etc.) or non-volatile memory ordata storage capable of performing the functions described herein.Volatile memory may be a storage medium that requires power to maintainthe state of data stored by the medium. Non-limiting examples ofvolatile memory may include various types of random access memory (RAM),such as dynamic random access memory (DRAM) or static random accessmemory (SRAM). One particular type of DRAM that may be used in a memorymodule is synchronous dynamic random access memory (SDRAM). Inparticular embodiments, DRAM of a memory component may comply with astandard promulgated by JEDEC, such as JESD79F for DDR SDRAM, JESD79-2Ffor DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, JESD79-4A for DDR4 SDRAM,JESD209 for Low Power DDR (LPDDR), JESD209-2 for LPDDR2, JESD209-3 forLPDDR3, and JESD209-4 for LPDDR4. Such standards (and similar standards)may be referred to as DDR-based standards and communication interfacesof the storage devices that implement such standards may be referred toas DDR-based interfaces.

In one embodiment, the memory device is a block addressable memorydevice, such as those based on NAND or NOR technologies. A memory devicemay also include a three dimensional crosspoint memory device (e.g.,Intel 3D XPoint™ memory), or other byte addressable write-in-placenonvolatile memory devices. In one embodiment, the memory device may beor may include memory devices that use chalcogenide glass,multi-threshold level NAND flash memory, NOR flash memory, single ormulti-level Phase Change Memory (PCM), a resistive memory, nanowirememory, ferroelectric transistor random access memory (FeTRAM),anti-ferroelectric memory, magnetoresistive random access memory (MRAM)memory that incorporates memristor technology, resistive memoryincluding the metal oxide base, the oxygen vacancy base and theconductive bridge Random Access Memory (CB-RAM), or spin transfer torque(STT)-MRAM, a spintronic magnetic junction memory based device, amagnetic tunneling junction (MTJ) based device, a DW (Domain Wall) andSOT (Spin Orbit Transfer) based device, a thyristor based memory device,or a combination of any of the above, or other memory. The memory devicemay refer to the die itself and/or to a packaged memory product.

In some embodiments, 3D crosspoint memory (e.g., Intel 3D XPoint™memory) may comprise a transistor-less stackable cross pointarchitecture in which memory cells sit at the intersection of word linesand bit lines and are individually addressable and in which bit storageis based on a change in bulk resistance. In some embodiments, all or aportion of the main memory 214 may be integrated into the processor 212.In operation, the main memory 214 may store various software and dataused during operation such as one or more applications (the application114), data operated on by the application(s), libraries, and drivers.

The compute engine 210 is communicatively coupled to other components ofthe client compute device 120 via the I/O subsystem 216, which may beembodied as circuitry and/or components to facilitate input/outputoperations with the compute engine 210 (e.g., with the processor 212and/or the main memory 214) and other components of the client computedevice 120. For example, the I/O subsystem 216 may be embodied as, orotherwise include, memory controller hubs, input/output control hubs,integrated sensor hubs, firmware devices, communication links (e.g.,point-to-point links, bus links, wires, cables, light guides, printedcircuit board traces, etc.), and/or other components and subsystems tofacilitate the input/output operations. In some embodiments, the I/Osubsystem 216 may form a portion of a system-on-a-chip (SoC) and beincorporated, along with one or more of the processor 212, the mainmemory 214, and other components of the client compute device 120, intothe compute engine 210.

The communication circuitry 218 may be embodied as any communicationcircuit, device, or collection thereof, capable of enablingcommunications over a network between the client compute device 120 andanother compute device (e.g., the edge gateway device 110, the edgeresources 140, 150, 160, 170, 180, etc.). The communication circuitry218 may be configured to use any one or more communication technology(e.g., wired or wireless communications) and associated protocols (e.g.,a cellular networking protocol, Wi-Fi®, WiMAX, Ethernet, Bluetooth®,etc.) to effect such communication.

The illustrative communication circuitry 218 includes a networkinterface controller (MC) 220, which may also be referred to as a hostfabric interface (HFI). The MC 220 may be embodied as one or moreadd-in-boards, daughter cards, network interface cards, controllerchips, chipsets, or other devices that may be used by the client computedevice 120 to connect with another compute device (e.g., the edgegateway device 110, the edge resources 140, 150, 160, 170, 180, etc.).In some embodiments, the NIC 220 may be embodied as part of asystem-on-a-chip (SoC) that includes one or more processors, or includedon a multichip package that also contains one or more processors. Insome embodiments, the NIC 220 may include a local processor (not shown)and/or a local memory (not shown) that are both local to the MC 220. Insuch embodiments, the local processor of the MC 220 may be capable ofperforming one or more of the functions of the compute engine 210described herein. Additionally or alternatively, in such embodiments,the local memory of the NIC 220 may be integrated into one or morecomponents of the client compute device 120 at the board level, socketlevel, chip level, and/or other levels.

The one or more illustrative data storage devices 222 may be embodied asany type of devices configured for short-term or long-term storage ofdata such as, for example, memory devices and circuits, memory cards,hard disk drives, solid-state drives, or other data storage devices.Each data storage device 222 may include a system partition that storesdata and firmware code for the data storage device 222. Each datastorage device 222 may also include one or more operating systempartitions that store data files and executables for operating systems.

Each accelerator device(s) 224 may be embodied as any device(s) orcircuitries configured to execute a set of operations faster than theprocessor 212 is capable of executing the operations. The acceleratordevice(s) 224 may include one or more field programmable gate arrays(FPGAs) 230, each of which may be embodied as a set (e.g., a matrix) oflogic gates that can be configured to perform a set of operationsaccording to a defined configuration (e.g., a bit stream). Theaccelerator device(s) 224 may additionally or alternatively include agraphics processing unit (GPU) 232, which may be embodied as any deviceor circuitry (e.g., a programmable logic chip, a processor, etc.)configured to perform graphics-related computations (e.g., matrixmultiplication, vector operations, etc.). Additionally or alternatively,the accelerator device(s) 224 may include a vision processing unit (VPU)234, which may be embodied as any device or circuitry (e.g., aprogrammable logic chip, a processor, etc.) configured to performoperations related to machine vision, machine learning, and artificialintelligence.

The edge resources 150, 152, 154 (e.g., the compute devices 160, 162,164, 166, 168, 170) and the edge gateway device 110 may have componentssimilar to those described in FIG. 2 with reference to the clientcompute device 120. The description of those components of the clientcompute device 120 is equally applicable to the description ofcomponents of the edge resources 140, 150, 160, 170, 180 (e.g., theaccelerator resources 140, 150, the storage resources 160, the computeresources 170, and the memory resources 180) and the edge gateway device110. Further, it should be appreciated that any of the edge resources140, 150, 160, 170, 180 and the edge gateway device 110 may includeother components, sub-components, and devices commonly found in acomputing device, which are not discussed above in reference to theclient compute device 120 and not discussed herein for clarity of thedescription. Further, it should be understood that one or morecomponents of a compute device may be distributed across any distance,and are not necessarily housed in the same physical unit.

The client compute device 120, edge resources 140, 150, 160, 170, 180and the edge gateway device 110 are illustratively in communication viaa network, which may be embodied as any type of wired or wirelesscommunication network, including global networks (e.g., the Internet),local area networks (LANs) or wide area networks (WANs), an edgenetwork, a fog network, cellular networks (e.g., Global System forMobile Communications (GSM), 3G, Long Term Evolution (LTE), WorldwideInteroperability for Microwave Access (WiMAX), etc.), a radio accessnetwork (RAN), digital subscriber line (DSL) networks, cable networks(e.g., coaxial networks, fiber networks, etc.), or any combinationthereof.

Referring now to FIGS. 3-6, the brokering logic unit 112 of the edgegateway device 110, in operation, may execute a method 300 fordetermining a physical implementation of a function to perform arequested workload from the client compute device 120. The method 300begins with block 302, in which the brokering logic unit 112 receivesinformation from a service provider. To do so, the brokering logic unit112 receives a performance function from the service provider asindicated in block 304. The performance function indicates a functionthat is required to execute the request (e.g., a portion of applicationto be performed by a set of edge resources) from the client computedevice 120. For example, the application running on the client computedevice 120 may require a set of edge resources to perform anacceleration sensitive function or a compute and memory sensitivefunction. If the performance function is to be used with the clientcompute device 120 that is embodied as a smart car, the performancefunction may define a set of accelerator resources to perform areal-time processing to support an acceleration sensitive application(e.g., autonomous driving).

In block 306, the brokering logic unit 112 further receives from theservice provider different physical implementations to perform theperformance function. As discussed above, each physical implementationof the performance function may indicate a set of edge resources and anoperating mode (e.g., a performance level) for each edge resource to beused to perform the performance function. For example, the serviceprovider may define different performance levels (e.g., differentlatency requirement for different application) of the same performancefunction (e.g., to provide different cost options to perform thefunction). In block 308, the brokering logic unit 112 receives abrokering logic from the service provider. The brokering logic definesan algorithm that is to be used to determine which physicalimplementation should be used to perform the performance function. Asdiscussed further below, the brokering logic unit 112 selects a physicalimplementation to perform an offloaded workload (e.g., a portion of anapplication that is running on the client compute device 120) requestedfrom the client compute device 120 using the brokering logic andparameters indicated by the client compute device 120.

It should be appreciated that, although information is described asbeing received from a single service provider in method 300, thebrokering logic unit 112 may receive information (e.g., one or morefunctions, physical implementations of each function, and a brokeringlogic associated with each service provider) from multiple serviceproviders.

If the brokering logic unit 112 determines that the information has notbeen received in block 310, the method 300 skips ahead to block 316 tofurther determine whether a brokering logic associated with any serviceprovider has been previously received. If not, the method 300 loops backto block 302 to continue to await information from a service provider.If, however, the brokering logic unit 112 determines that the brokeringlogic has been previously received from a service provider, the method300 skips ahead to block 324 of FIG. 4, which is discussed furtherbelow.

Referring back to block 310, if the brokering logic unit 112 receivedthe information from the service provider, the method 300 advances toblock 312. In block 312, the brokering logic unit 112 identifies a setof resources that provides access to perform the associated performancefunction. As discussed above, the service provider may own or operateone or more edge resources that may be positioned at one or more datacenters. In block 314, the brokering logic unit 112 determines whether aservice level agreement between the service provider and the identifiededge resources is satisfied.

If the brokering logic unit 112 determines that the service levelagreement is not satisfied, the method advances to block 316. Asdiscussed above, in block 316, the brokering logic unit 112 determineswhether a brokering logic associated with any service provider has beenpreviously received. If not, the method 300 loops back to block 302 tocontinue to await information from a service provider. If, however, thebrokering logic unit 112 determines that the brokering logic has beenpreviously received from a service provider, the method 300 skips aheadto block 324 of FIG. 4, which is discussed further below.

Referring back to block 314, if the brokering logic unit 112 determinesthat the service level agreement is satisfied, the method 300 skipsahead to block 318, in which the brokering logic unit 112 deploys theperformance function on each of the identified resources as indicated.Subsequently or concurrently, the brokering logic unit 112 registers theperformance function and the brokering logic at the brokering logic unit112, as indicated in blocks 318 and 320, respectively. It should beappreciated that it may be stored at any component of the edge gatewaydevice 110. In some embodiments, the brokering logic unit 112 maytransmit a notification to other service providers participating in theinfrastructure (e.g., to guarantee that a load balancing and brokeringscheme is fair and validated).

Referring now to block 324 of FIG. 4, the brokering logic unit 112receives a request from a client compute device 120. For example, therequest includes a section of an application that is requested to beoffloaded to a set of edge resources for execution. If the brokeringlogic unit 112 determines that a request has not been received in block326, the method 300 loops back to block 302 to continue determinewhether information has been received from a service provider. If,however, the brokering logic unit 112 determines that a request has beenreceived, the method 300 advances to block 328.

In block 328, the brokering logic unit 112 determines one or moreparameters associated with the client compute device 120 and/or anapplication running on the client compute device 120 that is providingthe request. For example, the parameters may include a requestedperformance function, a service level agreement (SLA) associated withthe client compute device 120, a maximum cost to perform the requestedperformance function, a list of acceptable service providers.Accordingly, in some embodiments, the brokering logic unit 112 maydetermine a performance function that is being requested by the clientcompute device 120 as indicated in block 330. Additionally oralternatively, the brokering logic unit 112 may determine a servicelevel agreement (SLA) that is associated with the requesting clientcompute device 120 as indicated in block 332. Additionally oralternatively, the brokering logic unit 112 may determine a maximum costto perform the requested performance function indicated by the clientcompute device 120 as indicated in block 334. Additionally oralternatively, the brokering logic unit 112 may determine a serviceprovider to be used to execute the requested performance function asindicated in block 336. For example, the request from the client computedevice 120 may include a list of acceptable service providers.

Subsequently, in block 338 of FIG. 5, the brokering logic unit 112selects a physical implementation to perform the requested performancefunction based on the parameters indicated by the client compute device120 using one or more brokering logics that are registered at thebrokering logic unit 112. To do so, for each performance function, thebrokering logic unit 112 may receive telemetry data from a centraloffice (e.g., a central data center) as indicated in block 340.Additionally or alternatively, as indicated in block 342, the brokeringlogic unit 112 may receive telemetry data from one or more data centers(e.g., where edge resources for the requested performance function arepositioned). The telemetry data for the performance function mayindicate a current load (or last known load and last known latency), oneor more physical implementations of the performance function, and aperformance level of each physical implementation. Accordingly, from thetelemetry data, the brokering logic unit 112 may determine a currentload or last known load or latency of the requested performance functionas indicated in block 344. Additionally or alternatively, the brokeringlogic unit 112 may determine different physical implementations of therequested performance function as indicated in block 346. Additionallyor alternatively, the brokering logic unit 112 may determine performanceof the requested performance function as indicated in block 348.

Once the physical implementation to perform the requested performancefunction is selected, the method 300 advances to block 350 of FIG. 6. Inblock 350, the brokering logic unit 112 determines whether a set of edgeresources of the selected physical implementation are indeed availableto perform the requested performance function. If the brokering logicunit 112 determines that the edge resources are available in block 352,the method skips ahead to block 360 to perform the requested performancefunction according to the selected physical implementation. If, however,the brokering logic unit 112 determines that the edge resources of theselected physical implementation are not available (e.g., due tosaturation of edge resources), the method 300 advances to block 354.

In block 354, the brokering logic unit 112 determines whether toschedule the requested performance function according to the selectedphysical implementation when the edge resources are not immediatelyavailable. To do so, in some embodiments, the brokering logic unit 112may compare time that is required to perform the requested performancefunction according to the selected physical implementation (e.g., waittime) and time that is required to find a next best physicalimplementation (e.g., routing time) as indicated in block 356. It shouldbe appreciated that the brokering logic unit 112 may determine a nextbest physical implementation at the same edge gateway device 110 or mayforward the request received from the client compute device 120 to adifferent edge gateway device to determine a next best physicalimplementation to perform the requested performance function.

If the wait time is shorter than the routing time, the brokering logicunit 112 determines to schedule the requested performance functionaccording to the selected physical implementation in block 358.Subsequently, the method 300 advances to block 360 to perform therequested performance function according to the selected physicalimplementation. Subsequently, the method 300 loops back to block 302 tocontinue to await information from a service provider to updateperformance function(s) and brokering logic(s) registered at the edgegateway device 110.

If, however, the wait time is longer than the routing time, thebrokering logic unit 112 determines not to schedule the requestedperformance function according to the selected physical implementationin block 358. Instead, the brokering logic unit 112 determines a nextbest physical implementation based on the brokering logics at the sameedge gateway device. Alternatively, in some embodiments, the brokeringlogic unit 112 may forward the request to a different edge gatewaydevice to determine a next best physical implementation based on one ormore brokering logics registered at that edge gateway device.Subsequently, the method 300 loops back to block 350 to determinewhether a set of edge resources of the next best physical implementationis available.

EXAMPLES

Illustrative examples of the technologies disclosed herein are providedbelow. An embodiment of the technologies may include any one or more,and any combination of, the examples described below.

Example 1 includes a device comprising circuitry in communication withedge resources, wherein the circuitry is to receive a brokering logicfrom a service provider; receive a request from a client compute device,wherein the request includes a function to be used to execute therequest and one or more parameters associated with the client computedevice; determine the one or more parameters; select, as a function ofthe one or more parameters and the brokering logic, a physicalimplementation to perform the function, wherein the physicalimplementation indicates a set of edge resources and a performance levelfor each edge resource of the set of edge resources; and perform, inresponse to a selection of the physical implementation, the requestusing the set of edge resources associated with the physicalimplementation.

Example 2 includes the subject matter of Example 1, and wherein therequest includes a section of an application to be executed by one ormore edge resources.

Example 3 includes the subject matter of any of Examples 1 and 2, andwherein the circuitry is further to receive data indicative of one ormore functions and different physical implementations of each function.

Example 4 includes the subject matter of any of Examples 1-3, andwherein the one or more parameters include a service level agreementassociated with the client compute device, a maximum cost to perform thefunction, and/or a list of acceptable service providers.

Example 5 includes the subject matter of any of Examples 1-4, andwherein the circuitry is further to receive telemetry data of thefunction to determine a current load or last known load of the function,different physical implementations of the function, and/or performanceof the function.

Example 6 includes the subject matter of any of Examples 1-5, andwherein the performance of the function includes a latency of each edgeresource associated with the different physical implantations of thefunction.

Example 7 includes the subject matter of any of Examples 1-6, andwherein the circuitry is further to determine whether the set of edgeresources of the selected physical implementation is available toperform the function.

Example 8 includes the subject matter of any of Examples 1-7, andwherein the circuitry is further to determine, in response to adetermination that the set of edge resources is not available, a nextbest physical implementation to perform the function.

Example 9 includes the subject matter of any of Examples 1-8, andwherein the edge resources include one or more accelerator devices, oneor more compute devices, one or more storage devices, and/or one or morememory resources.

Example 10 includes a method comprising receiving, by an edge gatewaydevice, a brokering logic from a service provider; receiving, by theedge gateway device, a request from a client compute device, wherein therequest includes a function to be used to execute the request and one ormore parameters associated with the client compute device; determining,by the edge gateway device, the one or more parameters; selecting, as afunction of the one or more parameters and the brokering logic and bythe edge gateway device, a physical implementation to perform thefunction, wherein the physical implementation indicates a set of edgeresources and a performance level for each edge resource of the set ofedge resources; and performing, in response to a selection of thephysical implementation and by the edge gateway device, the requestusing the set of edge resources associated with the physicalimplementation.

Example 11 includes the subject matter of Example 10, and wherein therequest includes a section of an application to be executed by one ormore edge resources.

Example 12 includes the subject matter of any of Examples 10 and 11, andfurther including receiving, by the edge gateway device, data indicativeof one or more functions and different physical implementations of eachfunction.

Example 13 includes the subject matter of any of Examples 10-12, andwherein the one or more parameters include a service level agreementassociated with the client compute device, a maximum cost to perform thefunction, and/or a list of acceptable service providers.

Example 14 includes the subject matter of any of Examples 10-13, andfurther including receiving, by the edge gateway device, telemetry dataof the function to determine a current load or last known load of thefunction, different physical implementations of the function, and/orperformance of the function.

Example 15 includes the subject matter of any of Examples 10-14, andwherein the performance of the function includes a latency of each edgeresource associated with the different physical implantations of thefunction.

Example 16 includes the subject matter of any of Examples 10-15, andfurther including determining, by the edge gateway device, whether theset of edge resources of the selected physical implementation isavailable to perform the function.

Example 17 includes the subject matter of any of Examples 10-16, andfurther including determining, in response to determining that the setof edge resources is not available and by the edge gateway device, anext best physical implementation to perform the function.

Example 18 includes the subject matter of any of Examples 10-17, andwherein the edge resources include one or more accelerator devices, oneor more compute devices, one or more storage devices, and/or one or morememory resources.

Example 19 includes one or more machine-readable storage mediacomprising a plurality of instructions stored thereon that, after beingprepared for execution, cause a compute device that executes theprepared instructions to receive a brokering logic from a serviceprovider; receive a request from a client compute device, wherein therequest includes a function to be used to execute the request and one ormore parameters associated with the client compute device; determine theone or more parameters; select, as a function of the one or moreparameters and the brokering logic, a physical implementation to performthe function, wherein the physical implementation indicates a set ofedge resources and a performance level for each edge resource of the setof edge resources; and perform, in response to a selection of thephysical implementation, the request using the set of edge resourcesassociated with the physical implementation.

Example 20 includes the subject matter of Example 19, and furtherincluding a plurality of instructions that in response to being executedcause the compute device to receive data indicative of one or morefunctions and different physical implementations of each function,wherein the one or more parameters include a service level agreementassociated with the client compute device, a maximum cost to perform thefunction, and/or a list of acceptable service providers.

1. (canceled)
 2. An apparatus comprising: at least one memory;instructions in the apparatus; processor circuitry to execute theinstructions to at least: determine a function to be used to execute arequest; select a first set of edge resources based on the function andone or more parameters associated with the request; determine a waittime for the first set of edge resources to become available to performthe function; in response to the determined wait time being greater thanzero, determine a predicted routing time to find a second set of edgeresources based on the one or more parameters; select one of the firstset of edge resources or the second set of edge resources based on acomparison of the wait time and the predicted routing time; and performthe function in response to the request using the selected one of thefirst set of edge resources or the second set of edge resources.
 3. Theapparatus of claim 2, wherein the one or more parameters include aservice level agreement associated with a device that generated therequest, a maximum cost to perform the function, and/or a list ofacceptable service providers.
 4. The apparatus of claim 2, wherein theprocessor circuitry to execute the instructions to, in response todetermining the wait time is zero, perform the function in response tothe request using the first set of edge resources.
 5. The apparatus ofclaim 2, wherein the request is generated by a smart car and thefunction includes real-time processing to support an accelerationsensitive application.
 6. The apparatus of claim 2, wherein theprocessor circuitry to execute the instructions to select a firstperformance level associated with the first set of edge resources. 7.The apparatus of claim 6, wherein the first performance level includes aminimum latency.
 8. The apparatus of claim 2, wherein the processorcircuitry to execute the instructions to access a brokering logicalgorithm from a service provider and wherein the selection of at leastone of the first set of edge resources and the second set of edgeresources is based on the brokering logic algorithm.
 9. One or morenon-transitory computer-readable mediums comprising instructions, whichwhen executed cause a processor to: determine a function to be used toexecute a request; select a first set of edge resources based on thefunction and a one or more parameters associated with the request;determine a wait time for the first set of edge resources to becomeavailable to perform the function; in response to the determined waittime being greater than zero, determine a predicted routing time to finda second set of edge resources based on the one or more parameters;select one of the first set of edge resources or the second set of edgeresources based on a comparison of the wait time and the predictedrouting time; and perform the function in response to the request usingthe selected one of the first set of edge resources or the second set ofedge resources.
 10. The one or more non-transitory computer-readablemediums of claim 9, wherein the one or more parameters include a servicelevel agreement associated with a device that generated the request, amaximum cost to perform the function, and/or a list of acceptableservice providers.
 11. The one or more non-transitory computer-readablemediums of claim 9, wherein the instructions, when executed, cause theprocessor to in response to determining the wait time is zero, performthe function in response to the request using the first set of edgeresources.
 12. The one or more non-transitory computer-readable mediumsof claim 9, wherein the request is generated by a smart car and thefunction includes real-time processing to support an accelerationsensitive application.
 13. The one or more non-transitorycomputer-readable mediums of claim 9, wherein the instructions, whenexecuted, cause the processor to select a first performance levelassociated with the first set of edge resources.
 14. The one or morenon-transitory computer-readable mediums of claim 13, wherein the firstperformance level includes a minimum latency.
 15. The one or morenon-transitory computer-readable mediums of claim 9, wherein theinstructions, when executed, cause the processor to access a brokeringlogic algorithm from a service provider and wherein the selection of atleast one of the first set of edge resources and the second set of edgeresources is based on the brokering logic algorithm.
 16. A methodcomprising: determining a function to be used to execute a request;selecting a first set of edge resources based on the function and a oneor more parameters associated with the request; determining a wait timefor the first set of edge resources to become available to perform thefunction; in response to the determined wait time being greater thanzero, determining a predicted routing time to find a second set of edgeresources based on the one or more parameters; selecting, by executingan instruction with a processor, one of the first set of edge resourcesor the second set of edge resources based on a comparison of the waittime and the predicted routing time; and performing the function inresponse to the request using the selected one of the first set of edgeresources or the second set of edge resources.
 17. The method of claim16, wherein the one or more parameters include a service level agreementassociated with a device that generated the request, a maximum cost toperform the function, and/or a list of acceptable service providers. 18.The method of claim 16, further including in response to determining thewait time is zero, performing the function in response to the requestusing the first set of edge resources.
 19. The method of claim 16,wherein the request is generated by a smart car and the functionincludes real-time processing to support an acceleration sensitiveapplication.
 20. The method of claim 16, further including selecting afirst performance level associated with the first set of edge resources.21. The method of claim 16, further including accessing a brokeringlogic algorithm from a service provider and wherein the selection of atleast one of the first set of edge resources and the second set of edgeresources is based on the brokering logic algorithm.